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REMARKS 

This Amendment is responsive to the Office Action mailed on September 27, 2004. 
Claims 1 and 17 are been amended. Claims 1-31 are pending. 

Claims 1-31 stand rejected under 35 U.S.C. § 102(e) as being anticipated by Vetro (US 
6,493,386). 

Applicants respectfully traverse these rejections in view of the amended claims and the 
following comments. 

Discussion of Amended Claims 

Independent claims 1 and 17 are amended to clarify that multiple re-encoded versions of 
the bit stream are produced, each version of the bit stream carrying the same content and having 
different rates , such that, once the overhead data is combined with each of the re-encoded 
bitstreams, multiple versions of the encoded (input) bitstream can be output. 

The present invention is useful, for example, in a television environment in which a client 
(e.g., cable or satellite television subscriber) may request a movie. As part of the request, the 
server may receive information about the network condition at the client end of the 
communication path, and can then transcode pre-compressed streams which carry the requested 
movie at the bandwidth required by the client end. In the event the server receives multiple 
requests for the same movie from different clients, and each client has a different bandwidth 
requirement, it will be necessary for the transcoder to provide multiple instances of the move at 
the different required bandwidths. 

A straightforward solution to this problem is to transcode the same input video stream at 
different rates as required by the different clients, as illustrated in Applicants' prior art Figure 3. 
A disadvantage of this solution is that the server is required to have as many different transcoders 
as the clients it serves. This is not realistic. 

Another solution is for the transcoder at the server to process the same video stream as many 
times as requested by different clients, but one at a time. In such system, as the server completes 
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the request by one client, the rest of the clients will have to wait their turn to see the requested 
movie or other service requested. Such a prior art system is shown in Applicants' Figure 4, 
wherein the transcoder 20 first provides Stream 1 from the compressed video bit stream, then 
provides Stream 2 after a delay 22, and then provides Stream N after another delay 22 (or series 
of delays depending on intervening requests), and so forth. Again, this is not a realistic solution 
as real-time provision of services on request is not provided. 

The present invention overcomes the problems noted above by providing a multi-rate 
transcoder which processes a single compressed bit stream, such as a video bit stream, and 
generates multiple versions of this stream at different rates. This process can occur upon request 
from a plurality of clients. 

Discussion of Vetro 

Claims 1-31 stand rejected under 35 U.S.C. § 102(e) as being anticipated by Vetro. This 
rejection is respectfully traversed. An anticipation rejection requires that each and every element 
of the claimed invention as set forth in the claim be provided in the cited reference. See Akamai 
Technologies Inc. v. Cable & Wireless Internet Services Inc., 68 USPQ2d 1 186 (CA FC 2003), 
and cases cited therein. As discussed in detail below, Vetro does not meet the requirements for an 
anticipation rejection. 

Vetro discloses a transcoder which converts an input bitstream having a first bit rate into 
an output bitstream having a second bit rate. For example, Figure 1 of Vetro discloses a 
transcoder 100 which includes a decoder 1 10 for fully decoding the input bit stream, and an 
encoder 120, which re-encodes the decoded bit stream at a new rate (Col. 2, lines 18-24). 
Similarly, the embodiment shown in Figures 3 of Vetro disclose re-encoding a single input 
bitstream into a single output bitstream at a different rate (see, e.g., Col. 6, lines 47-50). 

In contrast, with Applicants' claimed invention, overhead data is extracted from the input 
bit stream . The bitstream is then at least partially decoded, and then re-encoded at different rates 
to produce multiple re-encoded versions of the re-encoded bit stream . Each re-encoded bit stream 
carries the same content and has a different rate. The overhead data is then combined which each 
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of the re-encoded bitstreams so that multiple versions of the encoded bitstream can be output at 
different rates. 

Figure 6 of Vetro discloses a transcoder 600. An input bitstream 605 to the transcoder 
600 includes one or more object based elementary bitstreams. A demultiplexer 601 provides one 
or more of the object based elementary bitstreams to each of the object based transcoders 800. 
The transcoders provide object data to the transcoding control unit 610. The transcoders scale 
(reduce the bit rate) of the elementary streams. The scaled bit streams are passed to the 
multiplexer 602, which recombines them for output to a buffer 603, which outputs an output 
bitstream 605 having a different rate than the input bitstream 604 (Col. 10, line 52 through Col. 
11, line 9). 

As acknowledged by the Examiner, the object data carried by each elementary stream is 
different (Office Action, page 3, paragraph 4). Therefore, the Figure 6 embodiment of Vetro 
takes a multiplexed stream carrying multiple streams having different content , demultiplexes the 
multiplexed stream into its different streams, transcodes each of these different streams at a new 
rate using separate transcoders (one for each different stream), and then remultiplexes the 
different streams to provide an output multiplexed stream having a different rate than the input 
mutliplexed stream. 

The Figure 6 embodiment of Vetro is contrary to Applicants' claimed invention. With 
Applicants' claimed invention, the input bitstream is a single encoded bitstream , not a 
multiplexed stream as in Vetro. Further, with Applicants' claimed invention, multiple versions of 
the input stream are produced such that each version carries the same content but at different 
rates . In Vetro, each of the separate elementary streams of the multiplex carry different content, 
and only a single version of the input multiplex is provided as an output at the different rate. The 
multiplexing claimed by Applicants serves to recombine the extracted overhead data of the input 
bit stream with each re-encoded version of the bit stream and to output multiple versions of the 
encoded (original) bit stream at different rates . The multiplexing described in connection with 
Figure 6 of Vetro is used to combine the separately re-encoded elementary streams to form an 
output multiplex carrying different elementary streams. 
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Accordingly, Vetro does not disclose or remotely suggest Applicants' claimed scheme of 
providing a plurality of different rate output bitstreams from a common input bit stream . In 
particular, Vetro does not disclose or remotely suggest extracting overhead data from the input 
bit stream, at least partially decoding the input bit stream, re-encoding the at least partially 
decoded bit stream at different rates to produce multiple re-encoded versions of the bit stream, 
each version of the bit stream carrying the same content and having different rates, combining the 
overhead data with each of said re-encoded bit stre ams and outputting multiple versions of said 
encoded bit stream at different rates. 

Further, Vetro does not address the problems solved by Applicants' claimed invention. 
As discussed above in connection with Applicants' amended claims, by providing multiple 
versions of the same content stream at different rates , the same content (e.g., a video-on-demand 
movie) can be provided to multiple end users, each of which may have different bandwidth 
limitations. As Vetro discloses the transcoding of an input bit stream into a single output 
bitstream having a different rate, the system of Vetro cannot efficiently provide the same content 
stream to different users having different bandwidth requirements, without repeating the entire 
transcoding process separately for each user, resulting in unacceptable delays for the requested 
content. 

As Vetro does not disclose each and every element of the invention as claimed, the 
rejections under 35 U.S.C. § 102(e) are believed to be improper, and withdrawal of the rejections 
is respectfully requested. See, Akamai Technologies Inc., supra. 

Applicants respectfully submit that the present invention is not anticipated by and would 
not have been obvious to one skilled in the art in view of Vetro, taken alone or in combination 
with any of the other prior art of record. 

Further remarks regarding the asserted relationship between Applicant's claims and the 
prior art are not deemed necessary, in view of the amended claims and the foregoing discussion. 
Applicants' silence as to any of the Examiner's comments is not indicative of an acquiescence to 
the stated grounds of rejection. 
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Conclusion 

The Examiner is respectfully requested to reconsider this application, allow each of the 
pending claims and to pass this application on to an early issue. If there are any remaining issues 
that need to be addressed in order to place this application into condition for allowance, the 
Examiner is requested to telephone Applicants' undersigned attorney. 
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